1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



REMARKS 

Claims 15-31 were previously canceled. Claims 32-48 were previously 
added. Claims 1-14 and 32-43 are amended. Claims 1-14 and 32-48 remain in the 
application. In view of the following remarks, Applicant respectfully requests 
withdrawal of the rejections and forwarding of the application on to issuance. 



Specification Objection 

The Office has objected to the title of the present application and suggested 
that the title be changed. The Office argues that the title should contain key 
concept terms of the claimed invention. Applicant respectfully declines to change 
the title of the application and submits that the title is descriptive of the various 
claimed embodiments. As an example, consider the following. 

In the "Summary" section, the following summary of at least some of the 
disclosed material is provided. 

This invention concerns a system and related interfaces supporting 
the processing of media content. In accordance with one aspect of the 
present embodiment, a method of representing a development project is 
presented comprising identifying a plurality of sources comprising the 
development project, determining whether any of the sources are required 
simultaneously and, if not, dynamically generating a filter graph 
representation of the development project utilizing a segment filter to 
couple a source to multiple processing threads. In this way, the source and 
source filter, typically coupled to each of the multiple processing threads, is 
shared among multiple processing threads, reducing the computational and 
memory requirements necessary to support execution of the development 
project. 



Applicant respectfully submits that the individual claimed embodiments 
are, in some way, directed to reducing the computational and memory 
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requirements necessary to support execution of the development project as noted 
in the "Summary" section. Put another way, the various claimed embodiments are 
directed to, in some way, reduce source filter invocation in a development project. 
Hence, the title is not misdescriptive at all. Rather, the title adequately 
characterizes various claimed embodiments. 

Applicant has amended the specification to update the "Related 
Applications" section with the Applicant Serial numbers of the related 
applications. 

§101 Rejections 

Claims 1-12 and 32-43 stand rejected under 35 U.S.C. § 101 as being 
directed to non-statutory subject matter. Specifically, the Office argues that the 
claimed subject matter is software and that the software is not embodied on a 
computer readable medium. 

Applicant has amended the subject claims to recite that the claimed subject 
matter resides on a computer readable media. Accordingly, Applicant respectfully 
traverses the Office's rejection. 

§102/103 Rejections 

Claims 1 and 3-14 stand rejected under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 6,535,920 to Parry et al. (hereinafter "Parry"). 

Claims 2 and 37 stand rejected under 35 U.S.C. § 103(a) as being obvious 
over Parry in view of Official Notice taken by the Office. 
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Claims 32-36 and 38-48 stand rejected under 35 U.S.C. § 103(a) as being 
obvious over Parry in view of U.S. Patent No. 6,442,658 to Hunt et al. (hereinafter 
"Hunt"). 

Before undertaking a discussion of the substance of the Office's rejections, 
the following discussion of Applicant's disclosure is provided in an attempt to 
assist the Office in appreciating the patentable distinctions between the claimed 
embodiments and the material cited and applied by the Office. 

Applicant's Disclosure 

Perhaps a good place to begin to appreciate the various claimed 
embodiments is with a problem outlined in the "Background" section of the 
present application. Specifically, the "Background" section instructs that 
construction and implementation of filter graphs is computationally intensive and 
expensive in terms of memory usage. See, e.g. page 3, lines 12-21. As noted, 
even the most simple of filter graphs require an abundance of memory to facilitate 
the copy operations required to move data between filters. Thus, complex filter 
graphs can become unwieldy, due in part to the linear nature of conventional 
development system architecture. Moreover, it is to be appreciated that the filter 
graphs themselves consume memory resources, thereby compounding the issue 
introduced above. 

Thus, the various claimed embodiments are directed to systems which 
reduce the computational and memory resources required to support even the most 
complex of multimedia projects. 
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Consider now Applicant's Figs. 40-43 and the following discussion. The 
opening and processing of media represents consumption of memory and 
processing resources. Thus, performance improvements may be achieved by 
reducing the number of times a source is accessed. In the discussion that follows, 
a method is presented, in accordance with one embodiment, that serves to reduce 
the number of times a source is accessed, e.g., a method of source combining. It is 
to be appreciated, however, that the following is but one example implementation 
of the broader concept of reducing the number of times a source need be accessed 
during execution of a development project. 

Fig. 41 illustrates an example method of generating a filter graph, in 
accordance with one embodiment. As shown, method 4000 begins with block 
4002, wherein render engine 222 (Fig. 3) receives an indication to generate a 
development project. According to one implementation, render engine 222 
receives the indication from a higher-level application 216, e.g., media processing 
application 224, to assist a user in generating a processing project (e.g., a media 
processing project). 

In block 4004, render engine 222 identifies the number and nature of the 
media sources within the user-defined processing project, in preparation for 
generating a filter graph representation of the processing project. For each of the 
identified sources, render engine 222 determines the necessary transform filters 
306 required to pre-process the source (i.e., source chain), preparing the 
processing chain for presentation to the matrix switch filter 308 and one or more 
transition/effect filters 306. Unlike conventional implementations, which would 
proceed to generate the entire filter graph in preparation for execution of the 
processing project, render engine 222 generates a list of sources and when they are 
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required in the filter graph. According to one implementation, the list is referred 
to as a reuse list, and is maintained within render engine 222. An example of a 
data structure comprising a reuse list is presented with reference to Fig. 41. 

Turning briefly to Fig. 41, a graphical illustration of an example data 
structure comprising a source reuse list is presented. As shown, the reuse list 4100 
is comprised of a number of information fields, e.g., 4102-4110 which detail, in 
part, the relationship between clips in a track. More particularly, the reuse list 
4100 is shown comprising a track identification field 4102, a source identification 
field 4104, a project time field 4106 and a source time field 4108. 

Upon identifying a project source and the associated filters required for pre- 
processing the source (i.e., the source chain), render engine 222 assigns each track 
an identifier which uniquely identifies the source track within the context of the 
filter graph. In this regard, reuse list 4100 includes a field 4102 which maintains a 
list of tracks utilized in the associated project. In accordance with the illustrated 
example paradigm of the media processing system, the track identifier is utilized 
to represent a media clip from a given source. 

The source identifier field 4104 contains information denoting the project 
source associated with a particular track identifier. In this regard, the source 
identifier field 4104 may well contain a file name, a file handle, or any other 
suitable source identifier. 

The project time field 4106 denotes at what point during project execution 
the media clip is required. The source time field 4108 denotes what portion of the 
source file is required to support execution of the processing project. It should be 
appreciated that a user may well utilize the whole source file or any part thereof, 
as defined by the processing project. 
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In accordance with the illustrated example implementation of Fig. 41, two 
tracks are depicted 4110 and 4112. As shown, each of the tracks represent media 
from a common source (e.g., source ID 4213) and, the source media clips are 
adjacent to one another in the project (e.g., project time 4106) as well as within the 
source file (e.g., source time 4108). As will be developed more fully below, 
source clips may well be combined in certain situations into a single clip, as is 
represented by track 41 14 in Fig. 41 . 

Returning to Fig 40 and, in particular, block 4006, render engine 222 
reduces the number of source accesses where possible, in accordance with one 
embodiment. More particularly, render engine 222 analyzes the reuse list 4100 to 
identify opportunities to reduce the number of source accesses by combining 
source clips which meet certain criteria. According to one implementation, the 
criteria used by render engine 222 include one or more of (1) the source clips must 
occur next to one another in the project, (2) the clips appear next to one another in 
the source, and (3) the clips must share a common pre-processing source chain 
(i.e., must require the same pre-processing). If this criteria is met, render engine 
222 may combine the clips into a single clip. More specifically, render engine 222 
modifies the reuse list 4100 (Fig. 41) to replace the multiple source accesses 
(4110, 4112) with a single source access 4114 representing both source accesses as 
a single access. It is to be appreciated that removing a source access improves 
filter graph performance and, accordingly, the perceived performance of the 
development system by the user. 

In block 4008, once render engine 222 has reduced the number of source 
file accesses (block 4006), render engine 222 dynamically generates and manages 
the filter graph to support execution of the development project. In accordance 
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with one aspect, render engine 222 invokes only those source chains associated 
with sources that are necessary to support the current and/or impending execution 
of the filter graph. It is to be appreciated that by not opening each of the chains of 
a processing project, render engine 222 reduces the amount of memory required to 
build the filter graph, thereby reducing the amount of memory required to 
complete execution of the project. 

As introduced above, conventional media processing systems may generate 
an individual thread each time content was required from a source, even if the 
source had been accessed earlier. This redundant loading/unloading of a source is 
computationally expensive, and consumes precious memory resources. Extending 
the concept of source combining introduced above, a filter and related methods for 
sharing a common source and source filter among multiple processing threads will 
now be introduced. 

Turning to Fig. 44, a block diagram of an example filter graph 4400 is 
presented incorporating a segment filter 4406 which, as will be shown, 
dynamically couples a source filter to one or more processing chain. In 
accordance with the illustrated example of Fig. 44, filter graph 4400 is depicted 
comprising a source 4402, one or more pre-processing transform filters 4404, a 
segment filter 4406 and one or more pre-processing transform filter(s) 4408A-N, 
each coupled to a matrix switch 308 and rendering filter(s) 4410, 4412, 
respectively. 

As used herein, segment filter 4406 is designed to sit between a source 
filter and matrix switch 308 to provide multiple processing chains with source 
content from a single source, where it is impossible to combine the source clips (as 
introduced above). Render engine 222 invokes an instance of the segment filter 
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4406 after the greatest common pre-processing filter 4404 for each of the chains. 
That is, each of the processing chains may require the source content in a different 
format (e.g., size, frame rate, decode format, etc.). To the extent that the chains 
share common pre-processing attributes, those filter(s) (4404) are placed before 
the segment filter 4406 where practicable. In many instances, none of the chains 
share common pre-processing and the pre-processing filter(s) merely comprise the 
source filter. 

The segment filter 4406 acts as a controller, or throttle for the source, 
instructing the source filter to deliver content from source 4402 at select times. 
According to one implementation, the segment filter 4406 is, in turn, controlled by 
the render engine 222 and/or the matrix switch filter 308 to provide select content 
at select times on select inputs of the matrix switch filter 308. According to one 
implementation, the segment filter 4406 issues a "seek" command to the source 
filter to request particular content from the source. The source filter then delivers 
the requested content through the segment filter 4406 and appropriate pre- 
processing filter(s) 4408A-N to deliver the desired content to the requesting matrix 
switch 308 to support processing of the development project. 

As introduced above, render engine 222 is responsive to higher-level user 
interfaces, e.g., applications 224. In this regard, it is possible that the filter graph 
will receive user-commands while the filter graph is executing the development 
project. In accordance with the media processing system paradigm, for example, 
it is foreseeable that a user-invoked seek will be received by the filter graph during 
execution of the development project. Such user defined commands are typically 
serialized with commands issued by filters within the filter graph during the 
normal course of execution. In accordance with the illustrated example 
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implementation, where matrix switch 308 "throttles" execution of the filter graph, 
matrix switch 308 issues a seek command of its own to the source filter, requesting 
the information desired by the user. According to an alternate embodiment, seeks 
received from a higher-level application (and, therefore, representative of a user 
command) are afforded a higher priority within the filter graph. In such an 
implementation, all segment filters 4406 residing within the filter graph are also 
notified of such high-priority seeks, so that they can identify what content they 
will be required to provide next and, therefore, issue a revised seek command of 
their own. 

The remaining pre-processing transform filter(s) 4408A-N, matrix switch 
filter(s) 308 and rendering filter(s) 4410 each function as described in the 
application. 

Turning now to Fig. 45, an example method for generating a filter graph is 
presented. More particularly, the method of Fig. 45 is similar to the method of 
Fig. 42 wherein render engine 222 attempted source combining of source clips, 
which were not project and source time aligned, or which required unique pre- 
processing of some sort. In Fig. 42, however, if the source clips were not source 
time aligned (4204) and/or the clips required separate pre-processing (block 4206), 
each clip was assigned to a separate processing chain. In Fig. 45, however, this 
problem is resolved with introduction of a segment filter 4406. 

More specifically, with reference to Fig. 45, render engine 222 identifies 
multiple source clips from a common source which are not source time aligned, 
block 4204 and/or require separate pre-processing filter(s), block 4206. Render 
engine 222 generates a segment filter 4406 for the filter graph to reuse the source 
and at least the source filter, block 4502. That is, the render engine 222 inserts a 
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segment filter 4406 between the source filter and one or more processing chains to 
selectively provide otherwise disparate source clips from a single source. But for 
use of the segment filter 4406 in the filter graph, the method 4500 of Fig. 45 
executes in a fashion similar to Fig. 42, above. 

Turning now to Fig. 46, a flow chart of an example method of segment 
filter operation is presented. In accordance with the illustrated example 
embodiment of Fig. 46, the method begins in block 4602, wherein the segment 
filter 4406 seeks the source to the place that source data is first needed. As 
introduced above, segment filter 4406 receives a request for source content from 
matrix switch filter 308. It should be appreciated that insofar as segment filter 
4406 may well support a plurality of processing chains coupled to a plurality of 
matrix switch filters 308, a number of such requests may be received 
simultaneously. According to one implementation, each of the matrix switch 
filters 308 assigns a priority to the request for source content, wherein the priority 
of the request changes as the time the content is needed draws near. According to 
an alternate implementation, render engine 222 determines a priori whether source 
content will be required simultaneously and, if so, provides a separate source chain 
to accommodate such simultaneous content requests, thereby eliminating the 
situation of the segment filter 4406 receiving simultaneous requests. 

In block 4604, the source filter retrieves the requested content and passes 
the data to the switch until some sort of indication is received that the end of 
content has been received (e.g., an end-of-stream (EOS) indication, an application 
interrupt, etc.). As introduced above, an application interrupt may be issued when 
a user, through a user interface (e.g., media control application 224), wants to seek 
to a certain point in the development project. 
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In block 4606, segment filter 4406 determines whether an EOS or an 
application interrupt is received. If not, the process continues with block 4604. If 
so, segment filter 4406 identifies the next required segment and when it will be 
required, given the current seek location received from the matrix switch filter 
308. Based, at least in part, on the current seek location, segment filter 4406 
determines whether more segments of the source are required, block 4610. As 
introduced above, if a user-defined seek command is issued, it may be issued to a 
location in the development project where no further content is required from a 
particular source. Thus, segment filter 4406 determines whether additional 
segments are required in block 4610. 

If no further segments are required along one of the processing chains 
leading from the segment filter, render engine 222 may remove (at least 
temporarily) that chain from the filter graph to free memory space and a matrix 
switch filter input for other processing chains, block 4612. 

If, in block 4610 further segments are required, segment filter 4406 issues a 
seek instruction directing the source filter to retrieve and deliver the next segment, 
in accordance with the matrix switch filter instructions, block 4614. This process 
continues in an iterative fashion with block 4604. 

The Rejections 

Claim 1 has been amended and recites one or more computer-readable 
media embodying a software object for use in a media processing filter graph, the 
software object comprising [added language appears in bold italics]: 

• an input, coupled to a media source, to receive content from the 
media source; and 
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• a dynamically determined plurality of outputs, each responsive to the 
input and coupled to a source processing chain, to provide each of 
the source processing chains with media content requested from a 
single instance of the media source in accordance with a user defined 
media processing project, wherein said object is configured to reuse 
the media source by providing disparate source clips from said 
single instance. 



In making out the rejection of this claim, the Office argues that its subject 
matter is anticipated by Parry and cites to Parry's column 21, lines 12-25 in 
support therefore. Applicant has reproduced the content from this excerpt just 
below: 

By way of example only, a filter graph 640, the purpose of which is 
to play back MPEG-compressed video information from a file may take the 
form set out in FIG. 20A. Filter graph 640 includes source filter 642, 
MPEG parser 644, video decompression transform filter 646, audio 
decompression transform filter 648, video render filter 650 and audio 
render filter 652. Source filter 642 reads data from a disk and provides it as 
streaming information to MPEG parser 644. MPEG parser 644 parses the 
streaming information into its audio and video streams. Transform filters 
646 and 648 decompress the video and audio data in the corresponding 
streams. Render filters 650 and 652 act to display the video data on a screen 
and send the audio information to a sound card, respectively. 



With respect to the recited "dynamically determined plurality of outputs", 
the Office cites to Parry's parser. Applicant respectfully disagrees that the Parry's 
parser meets this claim element. Nonetheless, Applicant has clarified the subject 
matter of this claim to recite that software object "is configured to reuse the media 
source by providing disparate source clips from [the] single instance" of the media 
source. 
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The excerpt cited by the Office neither discloses nor suggests any such 
subject matter. Accordingly, for at least this reason, this claim is allowable. 

Claims 2-14 depend from claim 1 and are allowable as depending from an 
allowable base claim. In addition, in making out the rejection of claim 2 under § 
103, the Office takes Official Notice that "both the concept and advantages of 
alleviating each source processing chain from opening an independent instance of 
the source is well known and expected in the art." Applicant respectfully but 
strongly disagrees and respectfully requests that if such is the case, the Office 
produce a reference that discloses and teaches the same within the context of this 
material's usage in the claim. 

Claim 32 recites one or more computer-readable media embodying a 
software object coupled to a source processing chain in a media processing filter 
graph comprising: 

• a software object input, coupled to a media source, to receive content 
from the media source; 

• a dynamically determined plurality of software object outputs, each 
responsive to the software object input and coupled to a plurality of 
source processing chain, to provide each of the source processing 
chains with media content requested from a single instance of the 
media source in accordance with a user defined media processing 
project; 

• the source processing chain comprising: 

o a scalable, dynamically reconfigurable matrix switch having a 

plurality of inputs and a plurality of outputs; 
o at least one matrix switch input being communicatively 

linked with a first processing chain portion; 
o at least one other matrix switch input being communicatively 

linked with a second processing chain portion; 
o the matrix switch being configured to dynamically couple one 

or more of the matrix switch inputs to one or more of the 

matrix switch outputs. 
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In making out the rejection of this claim, the Office argues that Parry meets 
all of the subject matter of the claim, except for the subject matter that pertains to 
the matrix switch. The Office then relies on Hunt and argues that it teaches a 
"scalable, dynamically reconfigurable matrix switch... to improve playback of 
interactive multimedia content", citing to column 12, lines 6-58 for support. 

Applicant respectfully disagrees. The subject matter in Hunt relied on by 
the Office simply describes a representation of data in matrix form. For example, 
Hunt describes, in column 12 starting at line 18, the assemblage of probability 
factors in a table (Table 5) that indicate, in matrix form, the probabilities that 
segments will follow one another. Applicant respectfully submits that when Hunt 
is considered in its entirety, such data representation has nothing whatsoever to do 
with the recited scalable, dynamically reconfigurable matrix switch. 

Applicant respectfully submits that the Office has misquoted and taken 
Hunt out of context. Given this, the Office has failed to establish a prima facie 
case of obviousness and this claim is allowable. 

Claims 33-43 depend from claim 32 and are allowable as depending from 
an allowable base claim. In addition, in making out the rejection of claim 37, the 
Office takes Official Notice that "both the concept and advantages of alleviating 
each source processing chain from opening an independent instance of the source 
is well known and expected in the art." Applicant respectfully but strongly 
disagrees and respectfully requests that if such is the case, the Office produce a 
reference that discloses and teaches the same within the context of this material's 
usage in the claim. 
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Claim 44 recites a storage medium comprising executable instructions 
which, when executed, implement a system comprising: 

• means for coupling to a media source to receive content from the 
media source to provide an input; 

• means for dynamically determining a plurality of outputs, each 
responsive to the input and coupled to a plurality of source 
processing chains, to provide each of the source processing chains 
with media content requested from a single instance of the media 
source in accordance with a user defined media processing project; 

• the source processing chain comprising: 

o a scalable, dynamically reconfigurable matrix switch having a 

plurality of inputs and a plurality of outputs; 
o at least one matrix switch input being communicatively 

linked with a first processing chain portion; 
o at least one other matrix switch input being communicatively 

linked with a second processing chain portion; 
o the matrix switch being configured to dynamically couple one 

or more of the matrix switch inputs to one or more of the 

matrix switch outputs. 



In making out the rejection of this claim, the Office makes essentially the 
same argument that it did with respect to claim 32. Applicant respectfully submits 
that Hunt neither discloses nor suggests a scalable, dynamically reconfigurable 
matrix switch as utilized in this claim and described in Applicant's disclosure. 
Accordingly, the Office has failed to establish a prima facie case of obviousness 
and this claim is allowable. 

Claims 45-48 depend from claim 44 and are allowable as depending from 
an allowable base claim. 
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Conclusion 

All of the claims are in condition for allowance. Accordingly, Applicant 
requests a Notice of Allowability be issued forthwith. If the Office's next 
anticipated action is to be anything other than issuance of a Notice of Allowability, 
Applicant respectfully requests a telephone call for the purpose of scheduling an 
interview. 



Dated: 7 f / / 0 




(509) 324-9256 
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